home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1130.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.3 KB  |  63 lines
  1. In <9305111102.AA02689@www3.cern.ch> Tim discusses email & URLs:
  2.  
  3. Tim's suggested format for email URL:
  4.  
  5. >        mailto:user@host
  6.  
  7. Seems fine to me, except I would prefer the prefix "email:", as in
  8.  
  9.         <A TITLE="add www-announce" HREF="email:listserv@info.cern.ch">
  10.  
  11. I too am doubtful about including the mail headers as part of the URL,
  12. but note that the optional TITLE attribute for anchors can be used to
  13. specify a title field. Clicking this link would bring up a mail-window
  14. (e.g. "xterm elm listserv@info.cern.ch") so that the user can then
  15. type the body of the message and modify the headers.
  16.  
  17. Peter Lister's suggestion for the equivalent of a "paper reply-paid card"
  18. with boxes to be filled out by the customer, would be a good fit for a
  19. form, invoked by clicking the link. In this case the form would be specified
  20. as a separate document, which when completed is mailed rather than being
  21. sent back to the server.
  22.  
  23. > * The To: and From: fields of messages would be treatable
  24. > as hypertext links, just as the Newsgroup: and Reference: fields
  25. > are now.
  26.  
  27. Good idea.
  28.  
  29. > * A link type <LINK REL="AUTHOR" HREF="bloggs@acme.com"> would be
  30. >  a formal way of attributing responsability.
  31.  
  32. This is not at neat - the parser needs to know that REL="AUTHOR" implies
  33. that the HREF is an email address. It would be more straightforward to
  34. stick to the previous format and require the presence of the "email:" prefix.
  35.  
  36.         <LINK REL="AUTHOR" HREF="email:bloggs@acme.com">
  37.  
  38. Jim Davis comments:
  39.  
  40. > So though I have no specific syntactic proposal to make I
  41. > suggest reply mail might be either
  42. >  1) a special case of general programmatic invocation
  43. >  2) a special case of form-filling-queries
  44.  
  45. > On the other hand I recognize the trend of late in WWW to
  46. > implement special purpose features in an adhoc manner without
  47. > trying to design the ultimate feature set; and this may even
  48. > be a good idea given our lack of experience in the matter.
  49.  
  50. Jim, there is no need to implement special purpose features for this. We will
  51. be able to handle forms in a general way with HMML and the new HTRQ and HTTP
  52. protocols. The addition of "email:" (or mailto) to the URL format is
  53. a logical extension.
  54.  
  55. Cheers,
  56.  
  57. Dave Raggett
  58.  
  59. n.b. Jim, I am currently drafting a proposed standard for HMML (aka HTML+)
  60.      and will distribute the results real soon now. Send your input to
  61.      me c/o www-talk discussion group.
  62.  
  63.